home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group00b.txt / 000084_icon-group-sender_Thu Oct 19 15:51:56 2000.msg < prev    next >
Internet Message Format  |  2001-01-03  |  2KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id e9JMpXJ14175
  4.     for icon-group-addresses; Thu, 19 Oct 2000 15:51:33 -0700 (MST)
  5. Message-Id: <200010192251.e9JMpXJ14175@baskerville.CS.Arizona.EDU>
  6. Date: Thu, 19 Oct 2000 14:51:32 -0700 (MST)
  7. From: Gregg Townsend <gmt>
  8. To: icon-group
  9. Subject: Re: Pipes in Icon
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: RO
  12. Content-Length: 1378
  13.  
  14. >  From: "Charles Hethcoat" <CHETHCOA@oss.oceaneering.com>
  15. >  
  16. >  I would like to invoke a program /usr/bin/xyz from within an Icon program
  17. >  and use pipes to communicate with it.  I would send the command strings
  18. >  to xyz with a write(), and then read the results with a read()...
  19. >
  20. >  So the question is, is there any way to accomplish this entirely within
  21. >  Icon?  I'm sure I could with C, or with a bash script.
  22.  
  23. I contend that buffering problems make this infeasible from either C or
  24. Icon.  Most I/O libraries don't write anything to a pipe until they've
  25. filled a buffer, and the most likely consequence would be a deadlock,
  26. with each program waiting for the other to send more data.
  27.  
  28. >  From: Taybin Rutkin <trutkin@black.clarku.edu>
  29. >  
  30. >  ...What you're doing is creating a file at /usr/bin/xyz that is a pipe.
  31.  
  32. No, this is a misunderstanding of how Icon's open(..., "p") works.  It
  33. opens a pipe to a process; it doesn't create a named pipe.  That does
  34. suggest a possibile approach:  You could create a named pipe (using
  35. system("mkfifo /tmp/mypipe") or whatever) for a second channel to the
  36. spawned process.  But I still would predict deadlock.
  37.  
  38.    ---------------------------------------------------------------------------
  39.    Gregg Townsend         Staff Scientist      The University of Arizona
  40.    gmt@cs.arizona.edu     Computer Science     Tucson, Arizona, USA
  41.